Понимание компиляторов C++ от Java / перспектива C#
Переписать его как-то более эффективно.
$('.carousel').each(function(){
var $carousel = $(this);
$carousel.find("li").each(function(index){
$(this).addClass('thumbnail'+index);
$(this).css('background-image', 'url(' + $carousel.find('.item:nth-child(index) img').attr('src') + ')');
});
});
Хранение вашей карусели в объеме ее each() позволяет вам взаимодействовать с ней в объеме ваших li each(). Нет необходимости объявлять отдельную переменную i, так как первый аргумент, переданный функции в вызове each(), является индексом текущего элемента.
4 ответа
FAQ C++ является превосходным ресурсом обо всех особенностях C++, но он, вероятно, немного более совершенствуется, чем Вы ищете - большинством вопросов (не только ответы) являются тайны даже довольно опытным разработчикам C++.
Я думаю, гуглите ли Вы для учебных руководств C++, Вы сможете найти что-то. Можно также хотеть попытаться изучить ассемблер (или по крайней мере получить краткое введение относительно того, как вещи на самом деле происходят в микропроцессоре), как и C и C++ вполне близко к аппаратным средствам в способе, которым они делают вещи. Это - то, куда их скорость и питание прибывают из, но это прибывает в цену некоторых более хороших предложений Java абстракций.
Я могу попытаться ответить на Ваши конкретные вопросы, которые задают выше, но я не знаю, как хорошо я сделаю.
Один из ключей к пониманию отношений между заголовочными файлами и cpp файлами понимает идею "единицы перевода". Файл класса Java можно считать единицей перевода, поскольку это - основная единица, которая компилируется в двоичную форму. В C++ в значительной степени каждый cpp файл является единицей перевода (существуют исключения при выполнении странного материала).
Заголовочный файл может быть включен в несколько единиц перевода (и должен быть включен везде, который использует то, что определяется в заголовке). #include директива буквально просто делает текстовую замену - содержание включенного файла вставляется дословно, где #include директива. Вы обычно хотите, чтобы Ваш интерфейс класса был определен в заголовочном файле и реализации в cpp файле. Это вызвано тем, что Вы не хотите выставлять свои детали реализации другим единицам перевода, которые могут включать заголовок. В C++ все, включая классы, не является действительно богатыми объектами, но просто блоками памяти, которой компилятор присваивает значение... путем компиляции той же информации заголовка в каждую единицу перевода, компилятор гарантирует, что все единицы перевода имеют то же понимание того, что представляет блок памяти. Из-за отсутствия богатых данных после времени компиляции вещи как отражение невозможны.
Второй шаг в процессе сборки C++ связывается, который является, где компоновщик берет все скомпилированные единицы перевода и ищет символы (обычно вызовы функции, но также и переменные) используемый в единице перевода, но не определенный там. Это затем ищет другую единицу перевода, которая определяет тот символ и "соединяет" их, так, чтобы все вызовы к конкретной функции были направлены к единице перевода, которая определяет его.
В случае методов класса их нужно назвать через экземпляр класса, который является негласно просто указателем на часть памяти. Когда компилятор видит эти типы вызовов метода, он производит код, который вызывает функцию, неявно передавая указатель, известный как this указатель, к функции как первый аргумент. У Вас могут быть функции, которые не принадлежат классам (не методы, как Вы сказали, потому что метод является правильно функцией членства класса и таким образом не может существовать без класса), потому что у компоновщика нет понятия класса. Это будет видеть единицу перевода, которая определяет функцию и другого, который вызывает функцию, и свяжите их.
Это закончило тем, что было намного длиннее, чем я ожидал и конечно являюсь упрощением, но это с точностью до лучшего из моего знания, и уровень детализации, обеспеченный..., надеются, что это помогает некоторым. По крайней мере, это должно дать Вам начальную точку для некоторого поиска с помощью Google.
Это - что-то, что смутило меня, когда я сначала начал использовать C также. Книги не делают хорошего задания описания корректного использования заголовков по сравнению с файлами кода.
Компилятор работает путем загрузки каждого .cpp файла и компиляции его независимый от всего другие. Первый шаг в компиляции должен загрузить все заголовки, упомянутые #include операторами. Можно думать о нем делающий текстовую вставку целого foo.h везде, где существует #include "foo.h".
Каковы последствия этого для того, как структурировать Ваши файлы? Заголовочные файлы должны иметь любые части программы, необходимы, чтобы другие .cpp файлы относились к. Как правило реализации не должны быть в заголовочных файлах. Это вызовет проблемы. Заголовочные файлы должны включать объявления классов, функций и глобальных переменных (если необходимо использовать их).
Я на самом деле рекомендовал бы избегать объяснений о компиляторах C++ и посмотреть на объяснения в компиляторах C. По моему опыту, они объяснены лучше и стараются не путать Вас с проблемами ООП. Ищите материал о раздельной компиляции C. Я отослал бы Вас к замечательному буклету слайда от моей alma mater, но это не находится на английском языке.
Основное различие между компиляцией C и Java/C# - то, что компиляция не создает разрешенный объект. Другими словами, когда Вы компилируете в Java, компилятор ищет уже-компилируемые-файлы-класса для любых классов, на которые ссылаются и удостоверяется, что все доступно и последовательно. Базовое предположение - то, что, когда Вы в конечном счете запускаете программу, те файлы также были бы доступны.
Скомпилированный файл C, с другой стороны, является просто "обещанием". Это полагается на объявление того, на что зависимости были бы похожи (в форме объявлений функции), но нет никаких гарантий, что они определяются где угодно. Самый трудный переключатель мышления, который необходимо сделать, должен думать о файле C не так же, как о том файле, а скорее как агрегирование того файла со всем, что это включает (т.е. что препроцессор генерирует). Другими словами, компилятор не видит заголовочные файлы, это кажется одним большим файлом. Компилятор отслеживает в сгенерированном объектном файле всего, что "все еще отсутствует". Позже, во время ссылки, компоновщик делает, улаживает это путем попытки заполнить все пробелы материалами от различных объектных файлов.
Вы могли бы хотеть знать, почему компиляция и соединение являются отдельными также (так как я не вижу, что любые сообщения объясняют это, и это - причина большого количества беспорядка, не знающего базовые причины вещей).
Соединение и компиляция завершаются отдельно, потому что (и могла бы быть больше чем одна причина) потребности сделать вызовы библиотеки. если Вы определили, или любой его род, код, реализовывая прототипов функции в тех заголовках является частью libary, который уже компилируется и находящийся как объектный код где-нибудь. если бы гигантский процесс компиляции должен был использоваться то вместо этого, у Вас должен был бы быть источник для тех вызовов библиотеки, а также больше времени во время компиляции, потому что Вы будете также компилировать код библиотеки.